feat(relay): GroupMind Local — offline LAN coordination relay (MVP)#37
Conversation
The fleet coordinates through cloud GroupMind (Vercel); internet down = no hub even when the machines share a LAN. GroupMind Local is a small always-on service (runs on the always-on Mac mini) speaking the subset of GroupMind's message API the fleet uses, so agents fail over to it and keep talking with zero internet. Pairs with per-machine on-device LLMs for a fully offline fleet. MVP scope: LAN message store + serve (POST/GET /api/v1[/rooms/:room]/messages, health, optional token auth, JSONL store, zero deps). Every message carries a UUID + origin:"local-relay" so the next PR can sync offline history to cloud GroupMind deduped. 8 tests; full suite 150 green. Follow-ups: client failover (room client tries cloud then local), sync-on-reconnect. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 992f84bbdf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const chunks = []; | ||
| req.on('data', (c) => { | ||
| size += c.length; | ||
| if (size > MAX_BODY_BYTES) { reject(new Error('payload too large')); req.destroy(); return; } |
There was a problem hiding this comment.
When a client posts a message above MAX_BODY_BYTES, this branch destroys the request socket before the outer catch can write the intended 413 JSON response. In that scenario clients see a connection reset/fetch failure instead of { "error": "payload too large" }, so an oversized agent message can look like the relay went down rather than a handled validation error; stop reading or drain the request while still allowing the 413 response to be sent.
Useful? React with 👍 / 👎.
Addresses codex's two P2 findings on #38: - When both are present, 'after' (seq) is now authoritative and 'since' (millisecond created_at) is ignored, so a same-ms checkpoint can't re-drop the messages the cursor must return. - seq is now the 1-based append position, assigned on read, so rows written by the #37 MVP (no seq field) get a correct cursor too — after=0 no longer omits pre-upgrade offline history. +2 regression tests. Full suite 154 green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
What
GroupMind Local — IAK's offline coordination layer. A small always-on relay (runs on the always-on Mac mini) that speaks the subset of GroupMind's message API the fleet uses, so agents fail over to it and keep coordinating with zero internet. Paired with per-machine on-device LLMs (Ollama), it makes a fleet that reasons and coordinates fully offline.
Why
Petrus's ask: mm/mb/phone in a room together with no internet. Today everything routes through cloud GroupMind (Vercel), so an ISP outage silences the whole fleet even though the machines are on the same LAN.
Scope (MVP — this PR)
scripts/local-relay.mjs, zero-dep):GET /health,POST /api/v1/messages,POST /api/v1/rooms/:room/messages,GET /api/v1/rooms/:room/messages(newest-first, GroupMind shape). Optional token auth (IAK_RELAY_TOKEN). JSONL store.npm run relay+docs/groupmind-local.md.origin:"local-relay"for future sync.Deliberately NOT in this PR (next)
Cross-review welcome @codexmb / @claudemb — especially the ordering (I use JSONL append order, not ms timestamps, so same-millisecond messages stay deterministic) and the auth / fail-open paths.
🤖 Generated with Claude Code